Performance testing of an application measures one or more of the followings:                Response time: how the application performs when under load, i.e., what is the average response time during an average load and what is it during a peak load.        Capacity: what the maximum threshold for the application is under a given set of conditions, i.e., what is the maximum number of transactions (or pages) per second that the server can process and how many concurrent users are on the system at this point.        Scalability: how well the application responds to increasing load (requests to the server) by adding additional resources (which can be but are not limited to, more CPU's, memories, and physical boxes), i.e., how does the throughput change as we add resources and how does the response time change as users are added to the system.Most commonly, response time and the throughput of the system are used as measurements for these terms.        
Performance testing of an application can be a daunting and seemingly confusing task if not approached with the proper plan in place. Like any software development process, requirements must be gathered, business needs should be understood, and a formal schedule should be laid out well in advance of the actual testing. The requirements for the performance testing should be driven by the needs of the business and should be explained with a set of use cases. These can be based on historical data (say what the load pattern was on the server for a week) or approximations based on anticipated usage.
Early on in the development cycle of an application, benchmark tests should be used to determine if there are any performance regressions in the application. Benchmark tests are great for gathering repeatable results in a relatively short period of time. The best way to benchmark is by changing one and only one parameter between tests. For a non-limiting example, the impact of increases in Java Virtual Machine (JVM) memory on the performance of the application can be measured by incrementing the JVM memory in stages (going from say, 1024 MB to 1224 MB, then to 1524 MB and to 2024 MB) and stopping at each stage to gather the results and environment data, record it and then move on to the next test. This way there will be a clear trail to follow back when the results of the tests are analyzed.
Later on in the development cycle of an application, once the bugs have been worked out of the application and it has reached a stable point, more complex types of tests can be run to determine how the system will perform under different load patterns. These types of tests are usually referred to as: Capacity Planning, Soak Tests, and Peak-Rest Tests. These tests are designed to test real-world type scenarios by testing the reliability, robustness, and scalability of the application. For a non-limiting example, capacity planning tests are generally used with slow ramp-ups (defined below), but if the application sees quick bursts of traffic during a period of the day, then the test should certainly be modified to reflect this. Keep in mind that change of variables in the test (such as the period of ramp-up or the think-time of the users) will cause the outcome of the test to vary. Therefore, it is always a good idea to run a series of baseline tests first to set a known controlled environment to later compare your changes with.
There are many different ways to go about performance testing of an application, some of them more difficult than others. For repeatability, benchmark testing is the best methodology. However, to test the upper limits of the application in regards to concurrent user-load, capacity planning tests should be used.